home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / archiver / unix / unz50p1.zoo / inflate.c < prev    next >
Text File  |  1993-01-10  |  34KB  |  1,002 lines
  1. /* inflate.c -- Not copyrighted 1992 by Mark Adler
  2.    version c10p1, 10 January 1993 */
  3.  
  4.  
  5. /* You can do whatever you like with this source file, though I would
  6.    prefer that if you modify it and redistribute it that you include
  7.    comments to that effect with your name and the date.  Thank you.
  8.  
  9.    History:
  10.    vers    date          who           what
  11.    ----  ---------  --------------  ------------------------------------
  12.     a    ~~ Feb 92  M. Adler        used full (large, one-step) lookup table
  13.     b1   21 Mar 92  M. Adler        first version with partial lookup tables
  14.     b2   21 Mar 92  M. Adler        fixed bug in fixed-code blocks
  15.     b3   22 Mar 92  M. Adler        sped up match copies, cleaned up some
  16.     b4   25 Mar 92  M. Adler        added prototypes; removed window[] (now
  17.                                     is the responsibility of unzip.h--also
  18.                                     changed name to slide[]), so needs diffs
  19.                                     for unzip.c and unzip.h (this allows
  20.                                     compiling in the small model on MSDOS);
  21.                                     fixed cast of q in huft_build();
  22.     b5   26 Mar 92  M. Adler        got rid of unintended macro recursion.
  23.     b6   27 Mar 92  M. Adler        got rid of nextbyte() routine.  fixed
  24.                                     bug in inflate_fixed().
  25.     c1   30 Mar 92  M. Adler        removed lbits, dbits environment variables.
  26.                                     changed BMAX to 16 for explode.  Removed
  27.                                     OUTB usage, and replaced it with flush()--
  28.                                     this was a 20% speed improvement!  Added
  29.                                     an explode.c (to replace unimplode.c) that
  30.                                     uses the huft routines here.  Removed
  31.                                     register union.
  32.     c2    4 Apr 92  M. Adler        fixed bug for file sizes a multiple of 32k.
  33.     c3   10 Apr 92  M. Adler        reduced memory of code tables made by
  34.                                     huft_build significantly (factor of two to
  35.                                     three).
  36.     c4   15 Apr 92  M. Adler        added NOMEMCPY do kill use of memcpy().
  37.                                     worked around a Turbo C optimization bug.
  38.     c5   21 Apr 92  M. Adler        added the WSIZE #define to allow reducing
  39.                                     the 32K window size for specialized
  40.                                     applications.
  41.     c6   31 May 92  M. Adler        added some typecasts to eliminate warnings
  42.     c7   27 Jun 92  G. Roelofs      added some more typecasts (444:  MSC bug).
  43.     c8    5 Oct 92  J-l. Gailly     added ifdef'd code to deal with PKZIP bug.
  44.     c9    9 Oct 92  M. Adler        removed a memory error message (~line 416).
  45.     c10  17 Oct 92  G. Roelofs      changed ULONG/UWORD/byte to ulg/ush/uch,
  46.                                     removed old inflate, renamed inflate_entry
  47.                                     to inflate, added Mark's fix to a comment.
  48.    c10p1 10 Jan 93  G. Roelofs      version c10 plus Mark's c13 patch:
  49.            [c13]    M. Adler          allow empty code sets in huft_build (the
  50.                           new pkz204c.exe file has a null distance
  51.                       tree for the file pkzip.exe)
  52.  */
  53.  
  54.  
  55. /*
  56.    Inflate deflated (PKZIP's method 8 compressed) data.  The compression
  57.    method searches for as much of the current string of bytes (up to a
  58.    length of 258) in the previous 32K bytes.  If it doesn't find any
  59.    matches (of at least length 3), it codes the next byte.  Otherwise, it
  60.    codes the length of the matched string and its distance backwards from
  61.    the current position.  There is a single Huffman code that codes both
  62.    single bytes (called "literals") and match lengths.  A second Huffman
  63.    code codes the distance information, which follows a length code.  Each
  64.    length or distance code actually represents a base value and a number
  65.    of "extra" (sometimes zero) bits to get to add to the base value.  At
  66.    the end of each deflated block is a special end-of-block (EOB) literal/
  67.    length code.  The decoding process is basically: get a literal/length
  68.    code; if EOB then done; if a literal, emit the decoded byte; if a
  69.    length then get the distance and emit the referred-to bytes from the
  70.    sliding window of previously emitted data.
  71.  
  72.    There are (currently) three kinds of inflate blocks: stored, fixed, and
  73.    dynamic.  The compressor outputs a chunk of data at a time, and decides
  74.    which method to use on a chunk-by-chunk basis.  A chunk might typically
  75.    be 32K to 64K, uncompressed.  If the chunk is uncompressible, then the
  76.    "stored" method is used.  In this case, the bytes are simply stored as
  77.    is, eight bits per byte, with none of the above coding.  The bytes are
  78.    preceded by a count, since there is no longer an EOB code.
  79.  
  80.    If the data is compressible, then either the fixed or dynamic methods
  81.    are used.  In the dynamic method, the compressed data is preceded by
  82.    an encoding of the literal/length and distance Huffman codes that are
  83.    to be used to decode this block.  The representation is itself Huffman
  84.    coded, and so is preceded by a description of that code.  These code
  85.    descriptions take up a little space, and so for small blocks, there is
  86.    a predefined set of codes, called the fixed codes.  The fixed method is
  87.    used if the block ends up smaller that way (usually for quite small
  88.    chunks), otherwise the dynamic method is used.  In the latter case, the
  89.    codes are customized to the probabilities in the current block, and so
  90.    can code it much better than the pre-determined fixed codes can.
  91.  
  92.    The Huffman codes themselves are decoded using a mutli-level table
  93.    lookup, in order to maximize the speed of decoding plus the speed of
  94.    building the decoding tables.  See the comments below that precede the
  95.    lbits and dbits tuning parameters.
  96.  */
  97.  
  98.  
  99. /*
  100.    Notes beyond the 1.93a appnote.txt:
  101.  
  102.    1. Distance pointers never point before the beginning of the output
  103.       stream.
  104.    2. Distance pointers can point back across blocks, up to 32k away.
  105.    3. There is an implied maximum of 7 bits for the bit length table and
  106.       15 bits for the actual data.
  107.    4. If only one code exists, then it is encoded using one bit.  (Zero
  108.       would be more efficient, but perhaps a little confusing.)  If two
  109.       codes exist, they are coded using one bit each (0 and 1).
  110.    5. There is no way of sending zero distance codes--a dummy must be
  111.       sent if there are none.  (History: a pre 2.0 version of PKZIP would
  112.       store blocks with no distance codes, but this was discovered to be
  113.       too harsh a criterion.)  Valid only for 1.93a.  2.04c does allow
  114.       zero distance codes, which is sent as one code of zero bits in
  115.       length.
  116.    6. There are up to 286 literal/length codes.  Code 256 represents the
  117.       end-of-block.  Note however that the static length tree defines
  118.       288 codes just to fill out the Huffman codes.  Codes 286 and 287
  119.       cannot be used though, since there is no length base or extra bits
  120.       defined for them.  Similarily, there are up to 30 distance codes.
  121.       However, static trees define 32 codes (all 5 bits) to fill out the
  122.       Huffman codes, but the last two had better not show up in the data.
  123.    7. Unzip can check dynamic Huffman blocks for complete code sets.
  124.       The exception is that a single code would not be complete (see #4).
  125.    8. The five bits following the block type is really the number of
  126.       literal codes sent minus 257.
  127.    9. Length codes 8,16,16 are interpreted as 13 length codes of 8 bits
  128.       (1+6+6).  Therefore, to output three times the length, you output
  129.       three codes (1+1+1), whereas to output four times the same length,
  130.       you only need two codes (1+3).  Hmm.
  131.   10. In the tree reconstruction algorithm, Code = Code + Increment
  132.       only if BitLength(i) is not zero.  (Pretty obvious.)
  133.   11. Correction: 4 Bits: # of Bit Length codes - 4     (4 - 19)
  134.   12. Note: length code 284 can represent 227-258, but length code 285
  135.       really is 258.  The last length deserves its own, short